[Amazon Connect] Connectが東京リージョンに来たので、シドニーのコンタクトフローを移設してみました

SIN

2018.12.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

1 はじめに

AIソリューション部の平内（SIN）です。

本日、東京リージョンで利用可能になったAmazon Connect（以下、Connect）では、コンタクトフローのエクスポート及び、インポートが可能です。（どちらも、現在ベータとなっています）

今まで、シドニーで運用していたインスタンスを、東京に移行するニーズも多くなるだろう、という事で、コンタクトフローの移設を試してみました。

2 移行対象のフロー

題材として、Lambda の実行を含んだフローで、２つのフローが連携して動作しているものを準備しました。

(1) １つ目のフロー

１つ目のフローでは、Lambdaを実行して、２つ目のフローに遷移させてます。

exports.handler = async function(event, context) {
console.log(JSON.stringify(event));
return { message: "Lambdaのメッセージです" };
}

(2) ２つ目のフロー

２つ目のフローでは、１つ目のフローで実行したLambdaの戻り値を、プロンプト再生した後、キューに入れています。

正常に動作すると、以下のような流れになります。

接続
「最初のフローです」
「２つ目のフローです」
「Lambdaのメッセージです」
キューでの待機

3 エクスポート

問い合わせフローエディタの「保存」ボタンから「フローのエクスポート（ベータ）」を選択すると、コンタクトフローをJSON形式のファイルに出力することができます。

取得したJSONを開いてみると、各ブロックが配列で定義され、ブロックごとに振られたIDで、それぞれが接続されているようすを確認できます。また、別のフローや、Lambdaなどは、それぞれのARNで指定されています。

ARNには、リージョンや、ConnectのインスタンスIDが含まれていますが、東京リージョンに移すことで、この辺がどのようになるか確認していきたいと思います。

１つ目のフローの抜粋

{
"modules": [
{
"type": "SetVoice",
"parameters": [
{
"name": "GlobalVoice",
"value": "Mizuki"
}
],
・・・略・・・
},
{
"type": "SetLoggingBehavior",
・・・略・・・
},
{
"type": "Transfer",
・・・略・・・
"parameters": [
{
"name": "ContactFlowId",
"value": "arn:aws:connect:ap-southeast-2:**********:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/f0cf67dc-81dd-4e06-a504-36251c248486",
"resourceName": "SampleSecond"
}
],
・・・略・・・
},
{
"type": "PlayPrompt",
"parameters": [
{
"name": "Text",
"value": "最初のフローです。",
"namespace": null
},
],
・・・略・・・
},
{
"type": "InvokeExternalResource",
"parameters": [
{
"name": "FunctionArn",
"value": "arn:aws:lambda:ap-southeast-2:**********:function:Relocation_hello"
},
{
"name": "TimeLimit",
"value": "3"
}
],
・・・略・・・
],
・・・略・・・
"type": "contactFlow",
"start": "9639752f-7319-4106-b6ba-5317779db283",
・・・略・・・
}

4 インポート

東京リージョンにインスタンスを上げ、先のフローをインポートしてみます。

(1) １つ目のフロー

問い合わせフローを新規に作成して、保存メニューから「インポート（ベータ）」を使用して、先のフローをインポートしてみます。

読み込んだフローを「保存して発行」とすると、エラーとなります。これは、２つ目のフローへの遷移ブロックがありますが、まだ２つ目のフローが読み込まれていないためのエラーのようです。取り合えず、ここは「保存」としておきます。

(2) ２つ目のフロー

こちらも、「保存して発行」はエラーとなります。今度は、「キュー」が存在しないためです。ここも、一旦「保存」としておきます。

(3) キュー

キューについては、エクスポート・インポートが出来ないので、新規に作成する必要があります。

(4) 2つ目のフローの「保存して発行」

２つ目のフローに戻って、「保存して発行」をしてみましたが、やはりエラーとなってしまいました。恐らく、名前が同じでも、キューのARNが違うからだと思います。プロパティを開いて、選択リストの中からキューを選択しなおすことで、「保存して発行」が出来ました。

(5) 1つ目のフローの「保存して発行」

その後、１つ目のフローに戻っても、「保存して発行」はエラーでした。こちらもフローのARNの違いでしょう。プロパティを開いて、選択リストの中からフロー名を選択し直する「保存して発行」が出来ました。

(6) Lambdaの移行

Lambdaのコードを東京リージョンにDeployして、Connectの東京リージョンのインスタンスにパーミッションを与えます。

「AWS Lambda関数を呼び出す」ブロックは、エラーとはなっていませんでしたが、リージョンが変化してARNが変わっているので、変更は必須です。

5 各種ID

ここで移設前と後の各種IDを確認してみると以下のようになっていました。

フロー内の各ブロックのIDは、そのままで、インスタンスIDがインポート先のインスタンスIDに書き換わっています。また、フローのIDは、新しく採番されています。

リソース	リージョン	ARN
1つ目のフロー	シドニー	arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/d504ce50-e2ba-4596-969a-ba3981ed33d0
1つ目のフロー	東京	arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/contact-flow/f14e0a55-832f-4438-954c-0c18ceaca277
２つ目のフロー	シドニー	arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/f0cf67dc-81dd-4e06-a504-36251c248486
２つ目のフロー	東京	arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/contact-flow/67119a4f-4fbc-4a42-9d75-9d20cb6a8344
キュー	シドニー	arn:aws:connect:ap-southeast-2:{AWSアカウント}:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/queue/d4168d1a-a64a-4cdd-8945-c3411289b786
キュー	東京	arn:aws:connect:ap-northeast-1:{AWSアカウント}:instance/7fd93104-c08b-4b6e-b4b8-105de9729995/queue/e0ec924b-d857-4128-bcc0-e712f99e63e4
Lambda	シドニー	arn:aws:lambda:ap-southeast-2:{AWSアカウント}:function:Relocation_hello
Lambda	東京	arn:aws:lambda:ap-northeast-1:{AWSアカウント}:function:Relocation_hello